1. Field of the Invention
This invention relates to virtual machines of a computer processor such as a microprocessor. In particular, the invention relates to a virtual machine manager that may bind virtual machines to hardware contexts of a processor in a computer or other computing device.
2. Background
An Operating System (OS) is a software program that controls physical computer hardware (e.g., a processor, memory, and disk and CD-ROM drives) and presents application programs with a unified set of abstract services (e.g., a file system). A Virtual Machine Manager (VMM) is also a software program that controls physical computer hardware such as, for example, the processor, memory, and disk drives. Unlike an OS a VMM presents programs executing within a Virtual Machine (VM) with the illusion that they are executing on real physical computer hardware that includes, for example, a processor, memory and a disk drive. Each VM typically functions as a self-contained entity, such that software executing in a VM executes as if it were running alone on a “bare” machine instead of within a virtual machine that shares a processor and other physical hardware with other VMs. It is the VMM that emulates certain functions of a “bare” machine so that software executing within a VM executes as if it were the sole entity executing on the computer.
In order to accomplish this emulation it is necessary for some operations within a VM to be trapped and emulated by the VMM. The VMM may perform a sequence of operations on simulated hardware resources in order to maintain the illusion that a VM is actually interacting with real hardware. Transitions from a VM to the VMM and back will occur with some frequency, depending upon the number of tasks which the VMM must emulate for the VM. For example, a VMM must trap and emulate attempts to configure hardware devices. This may be achieved by the VMM via simulated hardware registers in system memory.
When executing “real-time” applications, computations upon data that is available at one substantially predetermined time should be completed by another substantially predetermined time. An OS that schedules a real-time application with sufficient frequency and for sufficient duration that the real-time application is able to complete its computations before their respective deadlines is said to have received adequate scheduling Quality of Service (QoS). Similarly, a VMM that includes a VM and a real-time OS (RTOS) provides adequate scheduling QoS when real-time applications and the VMs complete execution before respective deadlines. OSs and VMMs should schedule the computing resources of their real or virtual machine in such a fashion as to ensure that real-time applications receive adequate scheduling QoS.
Many current generation microprocessors such as, for example, the Intel® Pentium® 3 and 4 microprocessors include superpipelined out of order machines where instructions need not be executed in strict program order. While such processors typically have a number of independent execution units, they only fetch instructions from a single instruction stream. Some microprocessors, including some future members of the Pentium® family of processors, will have the ability to simultaneously fetch instructions from two or more instruction streams. These instruction streams are generally called threads because they correspond to threads scheduled by the system software. Microprocessors that simultaneously fetch instructions from two or more instruction streams are variously referred to as “hyper-threaded”, “multi-threaded” or “symmetric multi-threaded.” On hyper-threaded microprocessors the instruction fetch units are controlled by “hardware contexts”, which include both a stack pointer and an instruction pointer, a set of standard processor registers plus any additional state information necessary such as, for Pentium® family processors, control registers and translation look-aside buffer (TLB) tag bits. On out-of-order processors the nominal processor registers will generally be dynamically allocated from a pool of renameable registers, so that the actual static hardware context may be little more than a stack pointer, instruction pointer and a few control registers.